\chapter{Conclusions i treball futur}

\section{Conclusions}

Els objectius d’aquest projecte han anat creixent durant el seu desenvolupament.
Inicialment es pretenia adaptar dinàmicament únicament un lector de feeds per a
dispositius mòbils (referència al treball de'n Jordi Monné\cite{Monne}).\\

De seguida, però, es va proposar d’ampliar aquest horitzó. Gràcies a la
inspiració que va suposar per a nosaltres el descobriment del paradigma de la programació orientada a aspectes,
sorgí la idea de dur a terme el sistema pensat un pas més enllà i intentar
oferir una solució genèrica, que no es limités només a adaptar una aplicació específica.
Ja que es feia una solució genèrica també es va decidir
intentar afegir a la equació l’entorn d’escriptori.\\

Més tard, un cop es va veure que una solució d’aquest tipus era viable va ser el
torn de'n, de vegades estimat de vegades odiat, Juan Miguel López, codirector
del projecte. Ell va proposar anar una altre pas més enllà amb la idea
d’automatitzar el procés d’injecció del component client a les aplicacions.
Aquesta idea acabaria esdevenint el bloc web.\\

Hom podria pensar que ha sigut fàcil, doncs, el desenvolupament d’aquest
projecte, ja que s’han ampliat les premises reiteradament. No obstant, res més
lluny de la realitat. El camí ha sigut llarg, molt llarg, i també tortuós. Ens
hem hagut d’avarallar, literalment, amb entorns de desenvolupament madurs, però
que a l’hora d'integrar-los per a fer-los anar conjuntament resulten estar
carregats d’incompatibilitats, poca documentació al respecte de molts temes
tractats. Inclús al món web, una miríada de tecnologies cadascuna amb les seves
restriccions, on algunes de les restriccions, a més, depenen de la plataforma, i
un llarg, molt llarg, etcètera.\\

No obstant, creiem que ha sigut un final feliç, i hem pogut demostrar que una
solució d’aquestes característiques és viable. El resultat ha sigut una solució
força madura i pulida, i amb una capacitat de ser extesa molt gran, ja que
durant tot el desenvolupament del projecte s’ha tingut sempre en compte aquesta
posibilitat d’ampliació a pràcticament tots els nivells. A més la solució es
pot emprar per d’altres usos no pensats inicialment, aquests usos van des de
l’adaptació dinàmica de la interfície d’usuari depenent de nous factors no
proposats a aquest projecte fins a la posibilitat d’utilitzar-lo per a afegir
noves funcionalitats a les aplicacions. Sense aner més lluny, bona part de la
solució ha sigut emprada per una beca d'introducció a la recerca\cite{GRIHO} en
la que s'utilitzà per a incorporar estratègies de consciència de grup a una eina
col·laborativa, com a mecanisme per a acomodar la interfície d'usuari al context
d'ús i la capacitat cognitiva dels usuaris.\\

Moltes altres utilitats per aquest sistema estan
esperant a ser descobertes.


\section{Treball futur}

Durant el desenvolupament d’aquest projecte per temes de recursos de temps i/o
dificultat s’ha anat apuntant en quines parts es podria millorar tot el sistema,
les llistem a continuació.\\

\textbf{Afegir identificadors als widgets a l’afegir el component client a
una aplicació}\\
A l’hora de generar l’aplicació amb el component client incorporat, aquesta
podria passar per un filtre per a detectar tots els widgets que apareixen al
codi font que especifica la seva interfície d’usuari per a la llibreria gràfica
en concret. Un cop localitzats tots els widgets, es podria injectar codi al codi
font de l’aplicació de manera que aquests fossin identificables pel component
client i reportats als logs. Així, mitjançant més regles al motor d’inferència
al servidor, aquest seria capaç d’enviar propostes per modificar widgets
especificant a quin en concret es volen aplicar els canvis, cosa que ara mateix
no és possible realitzar ja que actualment només es poden proposar a un conjunt
de widgets identificats per les seves propietats, i no per una ID única. No fa
falta dir que el component client hauria de ser capaç, mitjançant els aspectes,
de localitzar també aquests widgets i aplicar els canvis sobre ells. El protocol
de comunicació també hauria de ser ampliat permetent identificar la ID de cada
widget loguejat en forma de xml.\\

\textbf{Tipus d'usuari en sessió}\\
Tant el disseny de base de dades com el seu model, així com part del codi del
servidor web esta preparat per suportar múltiples tipus de rol d’usuari en
sessió. Actualment només només esta plenament funcionant l’usuari administrador.
S’haurà d’acabar d’implementar en el servidor web aquesta funcionalitat.\\

\textbf{Guardar propostes de canvis de forma que el motor d’inferència pugui
utilitzar-los com a historial de resolucions}\\
Actualment les propostes de canvi a
la IU que genera el motor d’inferència són emmagatzemades a la base de dades en
cru, en forma de XML, tal i com s’han enviat al component client. Fòra positiu
per tal de poder escriure regles més precises i complexes que des d’una regla es
pugués accedir a les propostes que s’han enviat prèviament al client i quin ha
set el seu feedback, en forma de Beans. Per tal d’assolir això n’hi ha prou
amb parsejar el XML de les propostes que s’han enviat al client i afegir-lo al
conjunt de dades que manega el motor d’inferència, com a llista de Propostes de
canvis.\\

\textbf{Poder salvar l'estat de la creació de noves adaptacions}\\
Actualment si es perd la connexió amb el servidor, l’adaptació falla per un
motiu intern o simplement es desconnecta, tot el procés de creació d’adaptació
s’ha de fer des de el principi. Una funcionalitat molt útil seria el poder
guardar un llistat d’adaptacions que, per qualsevol motiu, no s’han pogut
finalitzar correctament. Seleccionar-ne una i continuar des de l’últim pas.\\

\textbf{Modificar adaptacions definides a la web}\\
Actualment les adaptacions són immutables. Això implica que si es desitgen
realitzar petits canvis en la seva definició l’única forma possible és
modificant directament la base de dades. Si es vol canviar quelcom sense haver
d’accedir a la base de dades s’ha d’esborrar la adaptació i tornar a crear-ne
una des de zero.\\

\textbf{Reports}\\
Actualment la web permet filtrar i obtenir en forma de txt els logs de l’usuari,
seria convenient posar-hi més condicions de cerca al filtre i utilitzar un
servidor de reports open source com ara Jasper Reports per a poder visualitzar
la informació de manera més organitzada.\\

\textbf{Canals de comunicació}\\
Actualment el pas de missatges entre component client i servidor només es fa a
través d’HTTP. Per a que les capacitats de comunicació fossin més variades es
podria implementar la part receptora del servidor com a servidor Bluetooth així
com enviar les dades des del client també via aquest canal. La solució actual
contempla la ampliació de canals de comunicació de forma senzilla. Només cal
implementar la interfície corresponent tal i com es mostra als annexes.\\

\textbf{Actualització dinàmica de la base de dades de dispositius mòbils}\\
Cada cop que ha de ser actualitzada la base de dades de perfils de dispositiu ha
de ser feta a mà. Els intervals d’actualització són reduïts, el fitxer poc pesat
i l’actualització es pot fer en calent, però la possibilitat de que aquest
mecanisme es pogués fer des de la pròpia web de forma automàtica.\\

\textbf{Desacoblar l’XML, abstraent el protocol de comunicació}\\
L’XML està força arrelat a diferents llocs de tota la solució. Es
possible abstreure el protocol de comunicació desacoblant l’XML dels Beans i les classes
clau que l’utilitzin de forma que pugui ser substituït per altres protocols més
eficients, segons el cas. Per exemple, si haguessin de conviure el component
client i el component servidor a la mateixa màquina un protocol basat en POJO’s
serialitzats seria molt més eficient.\\

\textbf{Component servidor incrustat}\\
En comptes d’incrustar obligatòriament només el component client a l’aplicació,
donar l’opció de, si el dispositiu objectiu té la suficient capacitat per
manegar-ho, incrustar també el component servidor (o una versió reduïda del
mateix). Aquesta opció es va contemplar al principi del projecte però de seguida
va ser posposada per qüestions de homogeneïtat quant a l’estructura global del
sistema, però amb una mica més d’esforç pot ser factible.\\

\textbf{Guardar les propostes de canvi de forma estructurada}\\
Actualment es manté a la base de dades un historial de les propostes de canvi
que s’ha enviat al component client. El problema és que aquestes propostes
s’emmagatzemen en cru, és a dir, es guarda íntegrament l’XML que s’envia al
component client. Si es guardés a la base de dades de forma estructurada es
podrien fer consultes sobre les propostes de canvi, i així podrien ser oferides
també al motor d’inferència per tal de proporcionar més dades amb les que crear
regles. Per fer viable aquesta opció caldria aplicar els següents canvis al
projecte:\\
\begin{itemize}
  \item Modificar la base de dades per a que els suporti
  \item Crear codi capaç d’estructurar i guardar aquesta informació al component
 servidor
 \item Crear codi que recuperi les propostes estructurades, les converteixi en POJO’s
 i les injecti al motor d’inferència
 \item Documentar l’ús d’aquests nous objectes a la documentació de generació de
 regles del motor d’inferència, a la web
\end{itemize}

\textbf{Suport per a aplicacions implementades amb altres llenguatges de
programació diferents de Java}\\
Actualment la solució proposada només suporta Java. El suport per a aplicacions
implementades amb altres llenguantges, però, no resulta difícil gràcies a
l’abstracció que ofereix el protocol de comunicació. De fet el sistema està
preparat per a aquesta proposta. El que caldria fer, però, és implementar un nou
component client en el llenguatge corresponent i afegir a la base de dades els
arxius corresponents per a poder compilar les aplicacions.
